home *** CD-ROM | disk | FTP | other *** search
Text File | 1994-05-08 | 89.1 KB | 2,144 lines |
- PCTOR V3.07
-
- PCTOR (c) Johan Forrer KC7WW 1991-1994
-
-
- Author: Johan B. Forrer KC7WW
- 26553 Priceview Drive
- Monroe, OR 97456
- United States of America
-
-
- Shareware notice
-
-
-
- This program is your registered copy of PCTOR and is not for
- distribution in any form. You may make as many copies for your
- own personal use. A Shareware version of the program is available
- from the author. PCTOR may not be sold or distributed with
- another product without the express written permission of the
- author. The author, Johan Forrer, KC7WW will only support
- unmodified copies of this software.
-
- If you are not satisfied with the program after registering it,
- you have 30 days from your registration date to return it for a
- full refund of your money, no questions asked.
-
- Previously registered users may obtain a free upgrade to this
- version - please send a formatted disk and SASE (or stamped
- mailer or 2 IRC's).
-
- This program may not be used by business or government
- institutions without proper licensing. Commercial users please
- contact Johan Forrer directly for modifications and/or details of
- site licensing.
- Acknowledgements
-
-
-
- The work and ideas of Peter Martinez, G3PLX, and Paul Newland,
- AD7I, has been the source and inspiration for doing the "nuts and
- bolts" in this project.
-
- Victor Poor's, W5SMM, helpful suggestions and ideas on
- compatibility with MBBIOS, PAMS/APlink, and the implementation of
- the extended ASCII set was invaluable.
-
- The helpful suggestions of Frank Gorichar, W7JUF, who beta tested
- early versions of this software is greatly appreciated. A special
- word of appreciation to beta tester Peter Ferrand, WB2QLL/1, with
- helping sort out various bugs. Malcolm, WA9BVS's beta testing has
- helped locate numerous obscure bugs.
-
- Thanks to Frank Wyatt, N6FW for forwarding technical
- documentation to me.
-
- Many individuals have sent in "wish lists", some of which are now
- part of the latest version. As always - your support, criticism,
- and suggestions are appreciated.
-
-
-
-
-
-
-
-
-
-
-
- Please support the efforts of shareware developers.
-
- Table of contents
-
-
-
- 0.0 Quick summary for this release.
-
- 1.0 PCTOR what does it do ?
-
- 1.1 Minimum requirements to run PCTOR
-
- 1.2 CAUTION
-
- 1.3 Planned enhancements
-
- 2.0 Introduction
-
- 3.0 Hardware Interface
-
- 4.0 Installation
-
- 4.1 Software
-
- 4.2 Customizing the configuration file
-
- 5.0 Operating PCTOR
-
- 5.1 Function keys
-
- 5.2 Command menu
-
- 6.0 Appendix
-
- 6.1 If problems persist.....
- 6.2 What if it still does not work .....
- 6.3 A few notes about HF modems.
- 6.4 Soft error detection and correction.
- 6.5 Frequencies of FEC stations for test purposes.
- 6.6 Signal analysis module.
- 6.7 DSP modem.
- 6.8 PCTOR update history.
- 6.9 1992 Newsletter
- 6.10 1993 Newsletter
- 7.0 Disclaimer
-
-
-
- 0.0 Quick summary for version 3.07
-
-
-
- -------------------------------------------------------
- THE FOLLOWING ANNOUNCEMENT IS IMPORTANT TO SOME USERS.
- -------------------------------------------------------
-
-
- In order to support an new DSP modem on the same COM port that
- PCTOR uses, versions higher than 3.05 now only supports
- transmitted data output though TxD, (pin 2 on a DB25 or DB9).
- This is due to the re-allocation of DTR for other purposes (the
- DSP uses it). It is essential to establish whether your serial
- port UART is suitable at higher baud rates - most modern serial
- ports will work without any problems, some older styles may will
- not work too well.
-
- Input and output mask options have been removed. These options
- only made sense when PCTOR was an AMTOR-only program. Ever since
- PCTOR included support for RTTY and now PacTOR, these mask
- settings often contradicted "normal" usage of RS232 signalling
- conventions. A general rule that holds for all modes now are:
-
- Mark (binary 1) = -12V
- Space (binary 0) = +12V
-
- PTT keyed = +12V
-
- This holds for RTTY/ASCII/AMTOR and HF Packet. Although PacTOR
- does not commit to any specifically. In order to be compatible
- with this convention, please check your modem and transceiver
- interfacing.
-
- If the TI DSK-based DSP modem is to be used with PCTOR, please
- make sure that it is connected to the serial port, powered up and
- ready for use. Also make sure that the "TOR.CNF" file contains
- the lines:
-
- dskmdm:2 .... this requests DSP modem support
- dskbaud:1 .... 1=115200 baud for DSK comms
- 2=(115200/2) baud for DSK
- 3=(115200/3) baud for DSK
- A value of 1 should work for faster machines,
- however, if you experience problems with loading
- the DSK, use a lower baudrate.
- dskrtty:1 ....
- dskascii:1 .... (Allocates which modem to use, see below)
- dskamtor:2 ....
- dskpactor:3 ....
- dskpacket:4 ..... 1=170 Hz shift 50 baud 2125/2295 FSK
- 2=170 Hz shift 100 baud 2125/2295 FSK
- 3=200 Hz shift 200 baud 2125/2310 FSK
- 4=200 Hz shift 300 baud 1600/1800 FSK
- 10=170 Hz shift 50 baud 1275/1445 FSK
- 11=425 Hz shift 50 baud 1275/1700 FSK
- 12=850 Hz shift 50 baud 1275/2295 FSK
- 20=170 Hz shift 50 baud 2125/2295 AFSK
- 21=170 Hz shift 100 baud 2125/2295 AFSK
-
- Further information on the DSK-based DSP modems are available in
- a separate document.
-
- Known Bugs:
-
-
- 1. Dos versions below 4.0 will not load hot key buffer. The
- reason is that in order to provide a sorted list of buffers,
- PCTOR uses the dir /o:n command. This option is not available in
- older DOS versions.
-
- New features:
-
-
- 1. For AN-93 users, the parallel port is chosen by the LPT
- parameter:
-
- lpt:x where x=1, 2 for LPT 1 or LPT 2. The default is LPT 1.
-
- 2. Any COM port (1 - 4) may be specified in the configuration
- file. Please make sure that your configuration file contain an
- entry:
-
- com:x where x=1, 2, 4, or 4
-
- 3. If a TI 320C26 DSK is used as a DSP modem, appropriate modem
- code will be loaded automatically when operating modes are
- changed.
-
-
- Bug fixes since version 3.03:
-
- 1. Some users reported that they experienced a system lockup
- after the initial screen. This was reported in cases where a
- sound card was installed in the system, and also with DOS 6. The
- problem was traced to a Compiler bug and required some minor
- rework of code.
- 1.0 PCTOR what does it do ?
-
-
- Using only a low cost external HF modem, PCTOR makes it possible
- to run AMTOR on PC compatible hardware without the need of
- dedicated multi-mode terminal node controller (TNC) hardware. All
- decoding is performed in software in real time using only PC
- hardware. The software has been tested to work even on a lowly
- 4.77 Mhz PC compatible.
-
-
- PCTOR will run under Microsoft Windows as a DOS application in
- full screen mode (please see the supplied .PIF file), however
- this kind of operation is presently not recommended. Future
- releases of PCTOR will be specific for operation under the
- Microsoft Windows platform.
-
-
- The main features of PCTOR could be summarized as:
-
-
-
- 1 - Split screen operation: Data received through the AMTOR
- translator is displayed on the upper window. The operator's
- keyboard entry is displayed on the lower window. A status
- window shows real-time operational status of the digital
- translator. This includes, timing, path propagation delay,
- link status, selcals, and more.
-
- 2 - All AMTOR modes are supported: ARQ, FEQ, and "Listen".
- Ascii/Baudot at any baudrate (practical maximum is 1200
- baud).
-
- 3 - The user may define several text buffers, i.e. brag tape,
- CQ messages, etc. that may be loaded for transmission with
- with one key stroke.
-
- 4 - Text files my be transmitted. Typically the user will
- prepare these off-line.
-
- 5 - Unshift-on-space (UOS) option.
-
- 6 - "PLX"-method of upper/lower case with extensions as
- developed by Peter Martinez (G3PLX), and Victor Poor
- (W5SMM).
-
- 7 - A "high" reliability option based on multiple bit sampling
- and majority voting. Memory ARQ for AMTOR is also supported.
-
- 8 - Receive data can be optionally be captured in a file.
- Automatic time stamps, as well as user-initiated time stamps
- may be entered into this capture file. The capture file can
- be read using an ordinary text editor.
-
- 9 - PCTOR can open a Dos shell (viable only for 386/486)
- with the low level AMTOR decoder running. The low
- level decoder has buffered I/O queues to accept traffic even
- when PCTOR has opened a DOS shell.
-
-
- 10 - The user can customize the working environment through use
- of a configuration file that is read when PCTOR starts up.
- Usage of a DOS environment variable "PCTOR" allows easy
- accommodation for a variety of operating environments.
-
- 11 - Keyboard entry is either in word-edit or character mode.
- When in word-edit mode, keyboard data is only entered into
- the type-ahead buffer when a space is entered (or carriage
- return, or the special symbol sequence "+?"). This way
- typing mistakes may be corrected before releasing them over
- the air.
-
- 12 - Advanced signal processing is available when using a special
- modem. This type of modem allows PCTOR to analyze internal
- circuit voltages in order to perform "soft" error detection
- and correction. Please see section 6.4 for further details.
-
- 13 - PCTOR's time may be set either for UTC or the user's local
- time.1.1 Minimum requirements to run PCTOR
-
-
- PCTOR will run on an IBM PC or close compatible computer. DOS 3.1
- or higher is required. A monochrome or EGA/VGA display adaptor
- will work. Although the software will run on a floppy-based
- system, a hard disk is recommended. The definition of "true IBM
- compatibility" is fuzzy and a great deal of flexibility has been
- built into the programs to handle a wide range of PC hardware.
- Please refer to the appendix where some further notes on dealing
- with incompatibilities are included.
-
- Some of the DSP options are only feasible on more powerful
- machines, i.e. 386 with co-processor or a 486.
-
- On the radio side, an HF modem, i.e. ST-6 or equivalent is
- required to decode received audio to +/- 12V RS232 logic signals.
- For transmission of AMTOR over the air, the user also has to
- provide a PTT interface and either AFSK or FSK. These interfaces
- are often included in an HF modem. If the software is used for
- monitoring only, only the HF modem is required. The HF modem is
- required to convert audio tones to RS232 compatible digital
- levels required by PCTOR (please see 6.3 for further notes on HF
- modems).
-
- PCTOR uses some of the signal lines of the standard COM1 or COM2
- serial ports as a digital interface (the user specifies which COM
- port - see "Installation - software"). 1.2 Caution
-
-
-
- This software may not be suitable for all working environments.
- The user should therefore proceed with the usual caution and make
- sure critical software is backed up.
-
- Every effort has been made to ensure that the software is "well
- behaved", however, the user is reminded that this software relies
- on critical timing. Normal system functionality is retained, i.e.
- time-of-day and floppy disk timeout activities. The user must
- thus be careful not to run other software that relies on similar
- "tricks" that PCTOR uses as the consequences are indeterminable.
-
- Normal program usage and program termination will undo the
- actions of PCTOR and restore normal system operation. Should a
- program failure occur, the only way to restore normal system
- operation is to reboot DOS.
-
- 1.3 Planned enhancements
-
-
-
- Several enhancements are planned for release in the near future.
- As a registered user you will be notified of these when it
- becomes available. These include:
-
- * PACTOR (a pre-release version is already available).
- * SAA/CUA standard interface (Windows Application).
- 2.0 Introduction
-
-
-
- PCTOR is an implementation of CCIR specification 476-2 on an IBM
- personal computer or compatible computer. As such, it replaces
- the need for dedicated TNC hardware and is an attractive
- alternative for the casual user evaluating a new operating mode,
- as well as the serious developer that needs to embed low level
- I/O functionality into a system.
-
- PCTOR contain a user-interface program that works in conjunction
- with several low-level routines that enables a user to operate
- and monitor TOR traffic with a minimum of fuss. Its
- multiple-window user interface allows simultaneous monitoring of
- decoded traffic, decoding status, and user keyboard history. Pop-
- up windows is used for setting operational parameters, file-I/O
- operations, and canned buffer transmissions.
-
- Function keys are used for quick, easy, and efficient control of
- most operations.
-
- PCTOR was developed using Borland C++ Version 3.1. The low-level
- interface was developed using Borland Turbo Assembler version
- 3.0.
- 3.0 Hardware interface
-
-
-
- PCTOR interfaces through signals of the COM1 or COM2 RS232 port.
- The following allocation of RS232 signals have been made: Other
- signal pins may be connected, however will play no part in the
- operation of PCTOR.
-
- Note that for a minimal interface, DTR, RTS, DCD, and Ground, is
- required. This will allow operation on AMTOR. For ascii/baudot,
- RD and TD must be utilized. If further software support for the
- tuning display or memory ARQ is required, a parallel port
- interface is required. Please contact the author for further
- details.
-
-
- For a 25-pin serial connector:
-
- pin 2 (TD) - output data bits (mark -12V, space +12V)
- pin 4 (RTS) - PTT (off -12V, on +12V)
- pin 8 (DCD) - input data bits (mark -12V, space +12V)
- pin 7 (Ground)
-
- The following link is required:
-
- pin 3 (RD) connected to pin 8 (DCD).
-
-
-
- For a 9-pin serial connector:
-
- pin 3 (TD) - output data bits (mark -12V, space +12V)
- pin 7 (RTS) - PTT (off -12V, on +12V)
- pin 1 (DCD) - input data bits (mark -12V, space +12V)
- pin 5 (Ground)
-
-
- The following link is required:
-
- pin 2 (RD) connected to pin 1 (DCD).
-
-
- When PCTOR is used in conjunction with the AN-93 analog modem,
- the parallel port interface is as follows:
-
- For a 25-pin parallel printer connector:
-
- pin 15 - AD0 (bits 0 - 4 from the A/D convertor)
- pin 13 - AD1
- pin 12 - AD2
- pin 11 - AD3
- pin 10 - AD4
-
- pin 1 - Strobe (strobe for A/D convertor)
-
- pin 18-25 - Ground
- 4.0 Installation
-
-
- 4.1 Software
-
-
- It is assumed that a hard disk is available, though the program
- can be run off a floppy disk as well. In fact it is suggested
- that you first run off a floppy disk to see if this software is
- compatible with other software that you may have on your system.
-
- 1. Create a new subdirectory and change directory to it, i.e.
-
- mkdir tor
- cd tor
-
- 2. Copy the contents of the floppy to the new subdirectory.
-
- copy a:*.*
-
- The following files will be copied:
-
- tor.exe -- The split screen AMTOR program.
- tor.cnf -- Setup file to custom configure your program.
- docs -- This documentation.
- brag.tor -- An example test file to load.
- cq.tor -- Another example file to load.
- test.tor -- A buffer file for demonstration of control
- characters
- AMTOR.BAT -- A batch file to run TOR with a parameter. Check
- to see which communications port COM 1 or 2 you
- desire.
-
- 3. Customize tor.cnf (see 4.2 "Customizing the configuration").
-
- 4. Create, or edit the files with ".tor" extensions. These files
- will be read when the program starts and will become the
- user's personalized buffers. These are transmitted by using
- the "hot" keys ALT-1 through ALT-9. The two included examples
- are typical.
-
- 5. Edit the the batch file "AMTOR.BAT" to suit your screen
- display color requirements (Please see section 9).
-
- 6. Run the batch file AMTOR, i.e. type AMTOR <enter>, or
- alternatively run it directly from the command line.
-
- 7. Make sure that you use the "ANSI.SYS" device driver in your
- DOS config.sys (please see about ANSI.SYS in your DOS manual).
-
- 8. There are three DOS environment variables that is worth
- knowing about. If you are not familiar with environment
- variables, type "SET" with no additional parameters at the DOS
- command line for the present list of environment variables on
- your machine. Some programs actually scans this list and may
- configure themselves accordingly. As far as PCTOR is concerned,
- your time zone, i.e. how many hours your are way from UTC time,
- and what abbreviation you would like to use for logging and
- operating purposes, is important. This environmental variable is
- called "TZ" and you typically include it in your autoexec.bat:
-
- set TZ=PST8 (I use this for setting Pacific Standard Time,
- that is 8 hours after UTC. Please consult your
- DOS manual).
-
- When you need to run PCTOR with say a bunch of different
- configuration files, or different ".tor" files, the "PCTOR"
- environment variable may be used to distinguish amongst them.
- Otherwise PCTOR will use the configuration file and ".tor" files
- in the local subdirectory from where you executed PCTOR from. If
- for example you need to use a different subdirectory for your
- configuration file than where your execute tor.exe, then the
- following command need to be typed at the DOS command line, or
- included your autoexec.bat (lets assume the configuration file is
- in c:\COMM):
-
- set PCTOR=c:\COMM
-
- The third environment variable that is of concern is COMSPEC.
- This variable tells PCTOR where to locate "command.com" when a
- dosshell is invoked (the F8 key). Usually the root directory is
- used, but there are instances where users specifically wish to
- locate their command.com elsewhere. DO NOT CHANGE the COMSPEC
- variable unless you are very familiar with DOS.
-
- 9. Several options are configurable from PCTOR's command line.
- This includes the type of display adaptor, the number of lines in
- each of the split screen displays, and the colors of displayed
- characters, messages, and annunciators. If you are using an
- EGA/VGA/SVGA display adaptor, the default settings will probably
- be adequate. In that case, leave out any further parameters on
- the command line.
-
- The general format of the command line format is:
-
- TOR [/B | /C | /M] [/Wxx] [/R] [[/SCxx] [/SExx] [/SBxx]
- [/SMxx] [/SAxx]]
-
- A command line parameters require the leading "/" followed by a
- directive such as B,C,M,W,R, or S. These parameters may be
- submitted in any order, each occurring only once. Note that for
- the display adaptor group, only one parameter, i.e. /B, or /C, or
- /M must be present. If for instance you have a monitor that has
- both color and black and white capabilities, and you desire to
- use a black and white display, use the /B. Using monochrome in
- this case will probably lock up your display.
-
- The significance of the command line parameters are given below.
-
- ┌───────────────────────────────────────────────────────┐
- │ Parameter Description │
- ╞═══════════════════════════════════════════════════════╡
- │ Display type (ONLY ONE OF THESE ALLOWED) │
- ├───────────────────────────────────────────────────────┤
- │ B Black and white on a color display │
- │ C Color │
- │ M Monochrome │
- ╞═══════════════════════════════════════════════════════╡
- │ Wxx Size of receive display (lines) │
- ╞═══════════════════════════════════════════════════════╡
- │ R Receive only - disable transmit facilities │
- ╞═══════════════════════════════════════════════════════╡
- │ Display color attributes │
- ├───────────────────────────────────────────────────────┤
- │ SCcc Received traffic character color │
- │ SEcc Echoed traffic character color │
- │ SBcc Background color │
- │ SMcc Message character color │
- │ SAcc Annunciator character color │
- └───────────────────────────────────────────────────────┘
- * The field xx indicates an integer number of lines.
- The field cc indicates a color code as given in the color table
- below.
-
- Certain restrictions apply to assignment of foreground and
- background colors. Example. The default settings are:
-
- TOR /C /W20 /SC7 /SE15 /SB1 /SM3 /SA14
-
- This translates to: Color display (CGA/EGA/VGA), 22 line receive
- display size, SC=Lightgray, SE=White, SB=Blue, SM=Cyan,
- SA=Yellow.
-
- Experience have shown that there are various types of monochrome
- display adapters around. Even those that are advertized as
- "Hercules" compatible often behave differently. Some of these
- monochrome display adapters could be used as being "color" as
- they will correctly map colors to the appropriate black/white
- attributes. Other monochrome adapters, however require the /M
- parameter and must not contain any color attributes. Some
- experimentation is necessary. Be warned that in some instances an
- inappropriate display selection may lock up your machine and
- require a reboot to recover.
-
- The receive-only command line option, /R, will disable all
- transmit facilities such as F1, F2, as well as functions that
- enter data into transmit buffers. It is also recommended in this
- instance to remove the keyboard-buffer window altogether using
- /W25.
-
-
-
-
- Color constants for setting PCTOR display attributes.
-
- ┌─────────────────────────────────────────────────────┐
- │ Color Constant Value Foreground or Background │
- ╞═════════════════════════════════════════════════════╡
- │BLACK 0 Both │
- │BLUE 1 Both │
- │GREEN 2 Both │
- │CYAN 3 Both │
- │RED 4 Both │
- │MAGENTA 5 Both │
- │BROWN 6 Both │
- │LIGHTGRAY 7 Both │
- │DARKGRAY 8 Foreground only │
- │LIGHTBLUE 9 Foreground only │
- │LIGHTGREEN 10 Foreground only │
- │LIGHTCYAN 11 Foreground only │
- │LIGHTRED 12 Foreground only │
- │LIGHTMAGENTA 13 Foreground only │
- │YELLOW 14 Foreground only │
- │WHITE 15 Foreground only │
- └─────────────────────────────────────────────────────┘
-
- 4.2 Customizing the configuration
-
-
-
- To enable a user to streamline the setup of the program to his
- requirements, a configuration file, "tor.cnf" is read during
- startup. Read and edit the contents of the provided file
- "tor.cnf" to suit your own preferences. This file is optional,
- but when not found, the system will use defaults. These entries
- are all optional, and may appear in any order, however, please do
- not enter any spaces between symbols,
-
- i.e.
-
- vid : 1 is NOT the same as vid:1
-
- (The last one is correct).
-
-
-
- The following entries may be customized:
-
- id:KCWW/KC7WW ----- set your identity selcal/callsign
- selcal:WDRZ/WA8DRZ/6 ----- set the startup selcal/callsign.
- wru:QRA KC7WW KCWW ----- your WRU text.
- com:1 ----- COM port to use 1= COM 1
- 2= COM 2
- 3= COM 3
- 4= COM 4
- lpt:1 ----- LPT port to use for AN-93 modems
- 1= LPT 1.
- 2= LPT 2
- opmode:0 ----- defines start-up mode 0 = AMTOR
- 1 = BAUDOT
- 2 = ASCII
- baud:45 ----- initialize BAUDOT/ASCII baudrate
- txdelay:30 ----- delay (ms) after PTT on till data
- out.This gives your transmitter
- time to changeover to transmit.
- cddelay:3 ----- delay (ms) after a data block is
- received before acknowledgement
- is sent. This gives the other
- station's receiver time to
- recover.
- timing:25 ----- system clock timing adjustment
- uos:0 ----- unshift-on-space OFF
- diddle:0 ----- RTTY diddle is OFF
- case:0 ----- upper/lower case OFF
- log:1 ----- receive data capture (logging)
- logfile:tor.log ----- data capture filename
- scrollfile:scroll.tmp ----- name of scroll file - if a
- ramdisk is available, use the
- full drive name here
- logprog:logger.exe ----- name of user's personal log
- program
- packetprog:pac.bat ----- name of user's packet program
- rel:0 ----- reliability OFF
- vid:1 ----- DIRECT video I/O enabled (see
- appendix on hardware
- compatibility)
- fcrlf:1 ----- Files, i.e. buffers and files to
- be sent through the ALT-F command
- should use the AUTOMATIC CR/LF
- mode. This means that all CR's in
- the input text files will be
- ignored, and LF will be
- interpreted as CR/LF.
-
- refr:15 ----- Status update rate. The number of
- system ticks between updates,
- i.e. 15*55mS=0.825 seconds. To
- fast a rate will flicker or
- perhaps may introduce timing
- problems, too slow will affect
- animation of timing bar, clock,
- etc.
- time:0 ----- Use local time in displays and
- logging. If UTC time is required,
- use time:1 (also refer to the TZ
- environment variable).
- tuning:0 ----- Disable software support for
- tuning display. To utilize this
- feature, use tuning:1. A
- special modem is required.
- marq:0 ----- Disable memory ARQ. Different
- levels of memory ARQ are
- recognized. Presently only level
- 1, "hard bits" is recognized.
- To utilize level 2 memory ARQ,
- i.e "soft bits", a special modem
- is required.
- word:1 ----- Turns word-edit mode on.
- stats:0 ----- Turns statistics off. When
- stats:1, displays the number of
- blocks received, number of blocks
- in error, and when memory ARQ is
- enabled, the number of blocks
- successfully reconstructed. These
- statistics are also inserted in
- the log file for later retrieval.
- dskmdm:0 -----DSP modem 0 = Use external modem
- 1 = Use DSK.
-
- Note that the syntax isn't tested very rigorously. Please check
- your input carefully against the supplied example.
-
- Both the AMTOR mode of PCTOR and RTTY/ASCII uses "common RS232
- convention" where:
-
- Mark (binary 1) = -12V
- Space (binary 0) = +12V
-
- PTT not asserted (open) = -12V
- PTT asserted (keyed) = +12V
-
- Until you have sorted out the required logic interfacing logic,
- prepare your transceiver for low power output into a dummy load
- (you may find your PTT unexpectedly comes on upon executing the
- program).
-
- Now run TOR. If your PTT comes on right away, the sense of RTS
- must be inverted before further testing can be done. Normally,
- TOR should put you in standby mode (PTT OFF).
-
- Next, on-the air tests will be necessary. Try to decode some FEC.
- FEC will be decoded while in standby mode. To make sure that you
- are in standby mode, hit F10. Tune in on an FEC transmission and
- wait for it to sync. If it fails to decode anything, first try
- changing the other sideband setting of your transceiver (if you
- normally use LSB, try using USB). This will show whether it's the
- interface logic or whether there is some other problem. If TOR
- receives FEC in the other sideband setting, the sense of DCD
- needs to be changed.
-
- The final test is to determine the logic level required for the
- transmitted data. Try an ARQ call. If it fails, you need to
- invert the sense of TxD.
-
- There is an additional timing-related entry, "timing:" that need
- to be set up. This parameter allows external adjustment of the
- system clock pulses to cater for systems with inaccurate clocks.
- Very few PC's have accurate clocks and although the default value
- (25) will work reasonable well in most cases, adjustment of this
- parameter is very desirable. For determining the value of this
- timing parameter, see 5.2 - Command menu: usage of the 'T'
- option.
- 5.0 Operating PCTOR
-
-
-
- Upon startup, the shareware banner may be displayed if you are
- suing the shareware version. In this case, press the ESC key to
- proceed to the PCTOR screen.
-
- The contents and layout of the status display line depends on
- which options the user has selected. The following description
- refers to the case when all the options are enabled. This gives
- the reader a description of all possibilities.
-
- PCTOR displays several windows: two status displays, the received
- traffic window, and the keyboard display.
-
- The smallest display is at the top of the screen, is the status
- window that is updated in real time and some machines may show
- some flickering. This is normal.
-
- Link status information, i.e. ARQ/BAUDOT/ASCII, IDLE, TFC, ERR,
- RQ, is displayed on the left hand side of the status line.
-
- Adjacent to the link status is the selcal/callsign of the remote
- station. This data is used in establishing the link and also for
- printing out identification data (see usage of the "Ins" key).
-
- Next, the programmed delays are shown: TD is the time (in
- milliseconds) that you allow, after the PTT signal has been
- activated, before data output will start. It is one way to
- compensate for slower on-switching equipment on your end. It
- allows for things to settle, before actual data is being sent.
- The default value (30 ms) is a reasonable compromise. CD is the
- time (in milliseconds) that allows the remote station's receiver
- to recover after it sent a block and is getting ready to receive
- your acknowledgment. The default of 3ms is reasonable. Actually,
- the total time before the user will be able to sample the
- acknowledgement is CD+TD. When you are sending blocks, however,
- then TD only plays a role. This split timing scheme allows for
- compensation in situations where the remote station experiences
- slower receiver recovery that transmit turn-on time. This is
- typical for local contacts.
-
- Once some traffic starts flowing, and you were the call
- originator on ARQ (i.e. the "Master"), the block receive time
- will be displayed. This is an internal timing parameter that
- cannot be changed. It includes the delay-parameters at both send
- and receive stations as well as the time delay due to the signal
- propagation through the atmosphere. If you notice considerable
- variation, then multipath propagation is most probably the
- reason, however, under high noise conditions, the simple types of
- modems may also pass too much pulse noise for the software to
- achieve good bit phasing lock.
-
- If the unshift-on-space (UOS) feature has been selected, this
- will be displayed as a µ symbol. This feature will shift letter
- shift when a space character is printed. Under noisy conditions,
- this will prevent the printing of data in the wrong case.
-
- If the user has selected the receive screen capture
- (autologging), the a ¢ symbol will be displayed.
-
- When the reliability option is selected a √ symbol will be
- displayed. Reliability is obtained by sampling each bit multiple
- times and using a majority voting.
-
- If the user selected upper/lower case operation, there will be
- two arrows, the first one is associated with the case of the
- receive text, while the second one is associated with the
- transmit case. An "up" arrow means upper case, while a "down"
- arrow indicates lower case.
-
- A 24 hour-format clock is also shown on the display. This clock
- is used for time stamps that are written to the log file, if
- enabled. The clock may be set for local time or UTC time (also
- see section 4.1 for details).
-
- An eleven bit analog indicator on the right hand side shows how
- bit phasing is progressing. During FEQ or ARQ, the indicator
- should show slow motion from right to left. The speed of the
- motion depends on how much your clock and the other station's are
- differing relative to each other.
-
- When the special TOR modem is used, and provided that the
- "tuning:1" option is set in the configuration file, a tuning
- indicator is displayed immediately below the bit phasing display.
- This tuning display consists of ten gradations each for mark and
- space simulating two bar-graph displays. The position of the
- indicator within the bar-graph display is proportional to energy
- passing through the mark and space filters in the modem's
- discriminator. When there is sufficient energy present, the color
- of the displayed indicator will change from a grayed outline to a
- solid color (red for mark and yellow for space on color
- displays). A well-tuned signal shows as two solid indicators that
- rests on the extreme end of the display. The display is quite
- steady and sharp.
-
- When using the "marq:1" option is used, the level 1 memory ARQ
- procedure is performed during ARQ reception. This involves block
- reconstruction from multiple bad blocks using "hard bits". Level
- 2 memory ARQ uses "soft bits" in addition to "hard bits",
- however, the special TOR modem is required. When memory ARQ has
- been successful in reconstructing a block, this is shown as "ERR"
- with green background instead of the usual red background.
-
- The second status line displays the name of the user-supplied log
- file, the name of the user-supplied executable (usually a logging
- program), statistics, and the size of the type-ahead buffers.
- 5.1 Function keys
-
-
-
- The function keys have the following functions:
-
- F1 - Initiate an FEC (Ascii/Baudot) call.
-
- F2 - Initiate an ARQ call.
-
- F3 - Force a change-over (works only in ARQ).
-
- F4 - Initiate QRT sequence (ends ARQ/FEC, Ascii/Baudot
- transmissions).
-
- F5 - If receive text capture is enabled, will insert a timestamp
- into the log file.
-
- F6 - Initiate ARQ listen mode.
-
- F7 - Clear keyboard type ahead and special buffers (used for
- WRU), clears keyboard display.
-
- SHFT F7 - Clears receive display.
-
- F8 - Open a DOS shell (use with care - 386/486 machines).
-
- F9 - Not used.
-
- F10 - Abort any operation in progress and revert to standby mode.
-
- End - Enter the +? sequence into the keyboard buffer.
-
- Ins - Enter an identification string into the keyboard buffer.
-
- Del - Force LTR case during receive (FEC/ARQ or Baudot). In
- addition will it reset the transmit and received cases to
- UPPER.
-
- Ctrl-Home - toggles "raw" data mode. For experimenters only -
- displays untranslated ITA2 (Baudot) code in Hex. This data
- is also written to the log for later analysis.
-
- ESC - Calls up the command menu when in user mode.
-
- Pgup/PgDn// - Scrollback, any other key will restore screen
-
- ALT-A Executes a signal analysis program. The modulation
- signal as recovered after the low pass filter of the modem
- is sampled and displayed in a graphics window. A second
- graphics window displays the frequency domain equivalent.
- Only EGA, VGA, and Hercules-compatibility is supported
- (also see Appendix for more on the signal analysis
- software).
-
- ALT-B - Enter the buffers menu. This allows a data buffer to be
- loaded into the keyboard buffer. The user prepares these
- buffers ahead of time using a text editor. These files have
- a "TOR" extension and will be loaded when TOR is
- initialized. Also note the usage of the ALT-1 through ALT-9
- keys as "hot" keys to load any of these buffers with one
- keystroke.
-
- ALT-C - Prompt user to enter the selcal/callsign of the remote
- station AND initiate an ARQ call immediately.
-
- ALT-D - Toggle RTTY diddle on/off.
-
- ALT-F - File transmission menu. Allows the transmission of text
- files while in FEC or ARQ. The transmitted text will be
- displayed as it is transmitted. There will be no echo to
- the receive window.
-
- ALT-H - Displays a help screen, showing the usage of the various
- function keys.
-
- ALT-M - "Hot keys" to the DSP modem control program.
-
- ALT-L - Activate the program named in the configuration file
- option "logprog". PCTOR remains running in the background.
- Upon termination of the user's program, the PCTOR display
- is restored.
-
- ALT-P - "Hot keys" to PC-PACTOR. Note that PC-PACTOR need to be
- available in the same directory than PCTOR.
-
- ALT-O - Toggles output to printer on/off.
-
- ALT-R - Prompt user for the selcal/callsign of the remote station
- WITHOUT initiating an ARQ call.
-
- ALT-T - Enter UTC time into the keyboard buffer for transmission
- in FEC or ARQ.
-
- ALT-W - Sends the "WRU" command to the remote station. This is
- the "figs-D" character in the ITA2 (Baudot) alphabet.
-
- ALT-X - terminates PCTOR in an orderly fashion. Equivalent to the
- "Q" option in the command menu.
-
- ALT-Y - "Hot key" to the packet program. Note that this typically
- is a batch file. The user must set this up the "packetprog"
- parameter in the configuration file. Please see
- section 4.2.
- 5.2 Command Menu
-
-
-
- The command menu (called up when the ESC key is pressed when in
- the main display) has the following one letter commands:
-
-
-
- C - Enable or disable upper/lower case operation.
- D - Set the cd and tx delays. CD is the time after reception of a
- data block until your acknowledgement is forthcoming. TD sets
- the time delay after the PTT is activated until data is sent.
- For local contacts CD=10, TD=30 will be suitable. For DX
- contacts CD=1, TD=10 is suitable. The default settings of
- CD=3, TD-30 is adequate for most modern radios.
-
- H - Help with the function keys.
- I - Set your own ARQ identity.
- K - Toggle between word-edit or character keyboard modes.
- L - Enable or disable receive capture (logging).
- O - Change operating mode AMTOR->BAUDOT->ASCII->AMTOR->...
- P - Change baudrate (300 max).
- Q - Terminate PCTOR.
- T - Set clock timing. This parameter allows fine adjustments of
- the master clock. See Appendix A for further details.
- U - Sets UOS (unshift on space) on or off.
- V - Toggles video mode (DIRECT/BIOS).
- W - Set up your WRU text.
- X - Exit the command menu to main display. The ESC key may also
- be used for this purpose.
- Y - Sends out a 500 HZ pulse train from pin 20 for diagnostic
- purposes.
-
- 6.0 APPENDIX.
-
-
- 6.1 If problems persists.......
-
-
-
- The most common feedback from users appears to be setting up
- PCTOR's master clock timing. Once this is done, the user enters
- the "magic" number into the configuration file that is used
- automatically each time the program is started. Only when
- installing the program on another computer will it be necessary
- to reset this timing parameter.
-
- Please note that this parameter has noting to do with the speed
- of your processor, or whether you use an 8088 or 486. Its about
- how to program a certain chip (8253/4) on the PC's motherboard.
-
- Typical symptoms will be that either nothing happens when trying
- to decode a FEC signal, or, the FEC sync is obtained, some text
- is printed, however, synch is lost and only a few words of
- garbage is printed before it starts re-sync. If you have a scope,
- or frequency counter available, try the following (its not
- serious if you do not have access to test equipment - you will
- just have to be a little patient and do some common-sense trial
- and error. It will take a little longer, but you will obtain the
- same end result. Skip the next paragraph if you do not have
- access to test equipment):
-
- Enter the command menu (Hit ESC) and select the "Y" option. This
- command should toggle the "Td" data pin at 500 Hz. Use the "+"
- and "-" keys to toggle the speed up or down, however, timing
- values above 30 and less than 18 are indicative of possible
- incompatiblities. Most systems work fine with the default of
- timing value of 25. When you have completed the test, return to
- the main display and select STANDBY (F10).
-
- Tune in FEC mode to a strong FEC broadcast station such as KMI
- WOO, or WLO (see attached list 6.5). Observe the timing indicator
- on the right hand corner of the status line. Notice that it may
- slide slowly. The objective is to have it as stationary or
- indecisive as possible. However, do not be concerned if you
- cannot get a perfect steady display, that is quite normal.
-
- Vary the timing value, one step at a time using the "+" or "-"
- keys. After changing the clock setting, the previous value as
- well as the new value will be displayed. You MUST then exit the
- command menu for the new settings to become effective. Once back
- to the main display, select STANDBY (F10) and wait for sync to be
- detected. Notice that when you return from the command menu to
- the main menu, you may see some received text being written to
- the receive display. This is text that have been accumulated by
- the low-level decoder and was stored in a system buffer while you
- were using the command menu. This text should be ignored as the
- changed clock setting was not yet in effect.
-
-
- Once the optimal setting has been found, modify the configuration
- file TOR.CNF to include the parameter for your system. Values
- ranging from 0 to 36 is valid. This procedure set the system
- clock close to +/-50ppm for stable AMTOR operation.
-
-
-
- 6.2 What if it still does not work ......
-
-
- At this point there remains one question: how "IBM compatible"
- your computer is. Perhaps your computer is quite compatible but
- there may be an interface adapter card that is not. It has been
- found that some video adapters does special emulation, i.e. runs
- one video mode, but allows some other type of equipment to be
- attached, i.e. ATI allows you to run VGA mode, yet allows you to
- use a CGA display. This kind of hardware introduces either wait
- states, or disables the interrupt system at a very low level.
- Since PCTOR needs a stable timing source, there will be a
- conflict for sure.
-
- PCTOR allows you to minimize these conflicts that are related to
- the video display by allowing the user to disable writing
- directly to the video memory. By selecting the "V" option in the
- command menu thus toggling BIOS on, all video access will be done
- through BIOS calls. The status line is also simplified to reduce
- the overhead. In some cases, this will do the trick. It is also
- possible to reduce the amount of screen-writing activity by
- slowing down the rate that the status line is updated (see 4.2
- "refr:15" ).
-
- Another problem that has been experienced with older PC
- compatibles, i.e. 1984 or so, is support chips on the motherboard
- that does not behave like later versions. Although these machines
- may be perfectly capable of running most software, they will not
- be able to keep accurate timing and may not work well with PCTOR.
- If possible, update the 8254 and 8259 chips. Also check the 8250
- UART for the same reason.
-
- Although there has not yet been reported problems on the use of
- serial/parallel interface cards using ASIC (Application-Specific
- Integrated Circuit) chips, some laptops and recent desktop
- machines are now using them. These ASIC's have varying levels of
- compatibility with the 8250-style chips and some are known to
- present real problems. The author uses both styles without
- problems, however, it is possible that the software may not be
- able to work in all situations. If your problems persist, as a
- last resort, check whether perhaps your system uses one of these
- ASIC's. Feedback on such problems will be appreciated - perhaps a
- solution may be forthcoming.
-
-
-
- 6.3 A few notes on HF modems
-
- Experience have shown that some modems perform better than
- others. We may divide the class of popular modems roughly into
- three categories (there are a few other types as well):
-
- (I) The phase locked loop (PLL),
-
- (II) filter type,
-
- (III) digital signal processing (DSP) type.
-
- It is the author's opinion that the PLL type of modems are not
- suitable for average HF operations. It is best to avoid this
- approach even with extensive front-end filtering.
-
- The filter-type modem have been used with much greater success on
- HF. However, there are various kinds of approaches in filter-type
- modems:
-
- Vintage designs like the ST-5 and ST-6 employed L/C filters and
- are known to work reasonably well, given that some changes are
- made to their low-pass filters (mainly to pass the 100 Hz AMTOR
- modulation rate).
-
- Active filter designs such as the DJ6HP will also work quite well
- under fair conditions, however, do not expect too much under
- adverse conditions. Another popular active filter modem is the
- BARTG design. This small modem will work reasonably well too,
- however it lacks front-end bandpass filtering, and has poor post-
- discriminator signal processing. Both these designs are good for
- newcomers.
-
- Modern good performance filter-type modems use sophisticated
- front end filters in conjunction with well-designed
- discriminators and extensive post discriminator filtering
- circuitry. They generally have excellent dynamic range to handle
- strong signals as well as being able to "dig into the noise" to
- handle weaker signals. They will tolerate some degree of off-
- frequency operation. It also has become popular to monitor analog
- levels of signals within the modem in order to implement "soft"
- error correction techniques. Although this does not necessarily
- mean an increase the level of hardware sophistication, additional
- interfacing and software support is required.
-
- The DSP approach is still new to HF operation, yet holds a lot of
- promise. There are presently some commercial units available.
-
- If you are interested in a small, yet sophisticated filter-type
- modem, with "soft" error correction capabilities, please contact
- the author for further details.
- 6.4 Soft error detection and correction
-
-
-
- With the introduction of PACTOR, soft error detection and
- correction entered the domain of HF communications for amateurs.
- The idea of soft error detection and correction has been
- described extensively in the literature, mostly in conjunction
- with high-speed satellite data links.
-
- A short introduction to soft error detection and correction, also
- termed "memory ARQ" follows:
-
- Most HF modems presently in use, does extensive signal processing
- to recover of the transmitted modulation. The output of the modem
- then is a stream of logical bits (zeroes and ones). These bits
- are then further processed by digital processing methods to form
- messages.
-
- It is, however, unfortunate that a great deal of useful
- information is lost when logical bits are produced by the modem's
- hardware. One can think of this thresholding as a one-bit analog-
- to-digital (A/D) conversion process (with resulting values zero
- and one). If this A/D conversion could have produced more
- resolution, i.e. eight, 16, or even 256 distinct levels, then it
- would have been possible not only have access to the resultant
- thresholded value, but also the magnitude of the signal at the
- time that it was thresholded.
-
- One application where knowledge of this magnitude is useful, is
- AMTOR ARQ mode. During AMTOR ARQ, blocks of three characters are
- transmitted on each chirp. The receiving station analyzes each of
- the three received characters for a possible error, and when an
- error is detected, it chirps back an RQ reply to the transmitting
- station to repeat the last three-character block. It is possible,
- and even probable when conditions are poor, that the
- retransmitted block may again contain an error. This may result
- in several repeated blocks. It is possible to improve on this
- "blind RQ" method by using memory ARQ.
-
- If the receiving station uses memory ARQ technique, it would have
- stored the A/D values associated with each and every bit of each
- of the three received characters. When an error is detected in a
- retransmitted block, i.e. after an RQ, an error-correction
- algorithm is then used to compute a "confidence" value for each
- character of the bad blocks (over two or more blocks).
- Subsequent block reconstruction then follows where a
- reconstructed block is made up from highest confidence elements.
- Such a reconstructed block is then error-tested again. More often
- than not, this results in fewer RQ's. PCTOR will show the actual
- statistics of how its doing. For HF conditions a success rate of
- 10% of received blocks in error, is achievable.
-
-
- 6.5 Some frequencies for FEC stations for test purposes
-
-
-
- Logged on: Fri Dec 11 1992 22:25:19 on 8431.5 KHz using PCTOR
- V2.02
-
-
- AT+T HIGH SEAS RADIOTELEX BROADCAST FREQUENCIES ARE AS FOLLOWS:
-
- +++++++++++++++++++++++++++++++++++++++++++++++++
- + ITU CHAN COAST-TX AT+T STATION +
- + -------- -------- ------------ +
- + 405 4212.5 WOO +
- + 412 4215.5 WOM +
- + 416 4217.5 KMI +
- + +
- + 626 6326.5 KMI +
- + 628 6327.5 WOM +
- + 629 6328.0 WOO +
- + +
- + 831 8431.5 KMI +
- + 833 8432.5 WOM +
- + 834 8433.0 WOO +
- + +
- + 1303 12630.0 KMI +
- + 1305 12631.0 WOM +
- + 1307 12632.0 WOO +
- + +
- + 1728 16870.0 KMI +
- + +
- + 1818 19689.5 KMI +
- + +
- + 2299 22425.5 WOM +
- +++++++++++++++++++++++++++++++++++++++++++++++++
-
-
-
- WX AND HIGH SEAS INFORMATION SCHEDULED BROADCASTS ARE AS FOLLOWS:
-
- STATION WX INFORMATION
- ------- ------------ --------------
- KMI ODD UTC HR+20 EVEN UTC HR+20
- WOM EVEN UTC HR+40 ODD UTC HR+40
- WOO EVEN UTC HR+20 ODD UTC HR+20
-
-
- 6.6 Signal analysis module
-
-
-
- Besides the benefits gained by memory ARQ, useful time domain
- signal analysis is possible especially when coming across an
- unknown signal. Time and frequency domain analysis software are
- provided as an external executable program that is accessible via
- a hot key from PCTOR. Acquisition of signal data is then
- initiated and interfacing with the signal processing program is
- relatively smooth and unintrusive.
-
- Two graphical displays are shown. One panel shows the actual
- analog signal with its software-thresholded counterpart, the
- other panel shows the frequency domain (RMS power spectrum). A
- software controlled cursor (using the left/right arrow keys),
- allows inspection of power spectral peaks, while different levels
- of magnification of the analog signal is user selectable (using
- the up arrow key). Continuous conversions are performed while the
- ALT key is held down. When the ALT key is up, the present state
- of the graphs are frozen.
-
- Unfortunately this type of work is only feasible on faster class
- machines. A 386/25 with math co-processor or a 486 processor is a
- pleasure to use. The signal processing software, however, has
- been tested on a 8 Mhz XT without math co-processor where it took
- several minutes to run to completion. Presently only Hercules,
- EGA, and VGA display adapters are supported.
-
- 6.8 DSP modem
-
-
- The advantages of DSP technology was already realized in the
- PCTOR's early days. At that time both hardware and the
- mathematics for applying DSP algorithms was not available.
- Affordable DSP hardware and the development of DSP modem software
- now makes the application of this technology very attractive.
- Besides being more cost-effective than its earlier analog
- counterparts, very high performance is possible. Being software
- upgradable, future developments are made relatively simple.
-
- The DSP modem firmware available for use with PCTOR is for usage
- on RTTY/ASCII, AMTOR, PacTOR, and HF Packet. The modem hardware
- is based on a TI 320C26 40 MHz and 14-bit codec. Communication
- with the DSP is though the same RS232 port that PCTOR uses. All
- firmware is downloaded to the DSP from the PC host.6.8 PCTOR upgrade history (since 2.03)
-
-
- Version 2.03
-
- 1) Supports baudot and ascii receive/transmit (baudot has the
- "diddle" feature). This includes the "O" and "P" options in the
- main menu to change modes of operation and transmission speed
- respectively. The PC's UART is used for this purpose and thus
- requires signals be routed to and from the uart appropriately.
-
- 2) UTC or local time may be optionally be selected.
-
- 3) Either word-edit or character keyboard modes may be selected
- (previously word-edit was standard). See the "K" option in the
- main menu..
-
- 4) F4 now also terminates mode-L
-
- 5) Some minor enhancements and bugs were fixed, i.e.
- - Reading the receive mask incorrectly from the .CNF file,
- - Cleanup of the CR/LF sequence associated with F5 usage,
- - Cleanup of the display when using a DOSSHELL (F8),
- - Better validation of setup parameters from the .CNF,
- - Allow the usage of "?" for help in the main menu.
-
-
- 6) Optional software support for a companion modem. This includes
- an analog mark/space tuning display on the PCTOR status line. It
- also allows future development of "soft" error detection and
- correction using "memory ARQ". This development is needed to
- fully support PACTOR.
-
- 7) If you are not interested in ascii/baudot operation, no
- changes are needed in your RS232 hardware interface to use
- version 2.03. If you are interested in using ascii/baudot,
- however, please see 3.0 for additional interfacing requirements.
- If you are further interested in using the software tuning
- indicator display feature, the companion modem is required as
- well as a parallel port interface.
-
- 8) Older versions of PCTOR (pre-1.17) used a terminate stay
- resident (TSR) program, called TORBIOS. PCTOR now incorporates
- all low-level routines previously performed by the TSR.
-
- 9) ALT-A "spawns" a special module for modulation analysis. This
- involves taking 1024 data samples from the modem's low pass
- filter stage, performing an FFT and displaying both analog and
- frequency domain waveforms. This allows future development of
- analysis of received audio. IMPORTANT NOTICE: Do not attempt this
- function on a 8088 or 80286 type processor - it works but takes
- several minutes to perform the calculations. Only a 386/25 with
- co-processor or a 486/33 can do justice to this analysis. At this
- time, only EGA, VGA, and Hercules compatible displays are
- supported.
-
- 10) ALT-L "spawns" any program the user wishes to execute when
- this key is pressed. Typically this would be a logging program.
-
- 11) The log filename and name of the ALT-L user program is
- displayed on the status line.
-
- 12) There is an option to enable memory ARQ (MARQ) for AMTOR.
- When active, "ERR" is displayed with a green background instead
- of the usual red background when processing error blocks. The
- MARQ algorithm is similar to that used for PACTOR. This first
- level of memory ARQ is based on "hard bits" and will work with
- any modem. It does not require the special modem. Future levels
- of memory ARQ will also make use of "soft bits".
-
- 13). The help screen "ALT-H" is expanded to include an
- explanation of the different flags associated with various
- options.
-
-
- Version 2.04
-
- 14) ALT-X may now be used for quick exit (tnx SV1BDS).
-
- 15) Command.com (the dosshell) is now located through the COMSPEC
- environment variable (tnx SV1BDS).
-
- 16) All files, i.e. TOR.CNF or *.TOR files are now located
- through the environment variable "PCTOR" (please see 5.0 for
- application notes) (tnx SV1BDS).
-
- 17) Baudot and ascii operations now echo transmitted text to the
- receive screen.
-
- 18) Any baudrate not greater than 300 bps is allowed on
- baudot/ascii, however, only integer values must be entered. The
- amateur standard of 45.45 baud is a special case where a baudrate
- of 45 will be interpreted as meant to be 45.45 bps (tnx SV1BDS).
-
- 19) The delay parameter called TX-DELAY have now been split into
- two parts, TD (transmitter turn-on delay), and CD (control delay)
- (for further details please see section 4.2 on customizing the
- configuration file) (acknowledgement to Bill Henry, K9GWT, QST
- June 1992, p.34-45).
-
- 20) PCTOR now dynamically locates a free user-interrupt slot in
- the range 60h-67h. Previously 60h was hooked, however this may
- have caused a problem is some instances. If there is none
- available, the user will be notified and prompted, otherwise
- installation will proceed as usual without any intervention.
-
- 21) The special option indicator symbols on the upper command
- line started crowding the time clock digits, so they were moved
- down a line to the right of the PCTOR logo.
-
- 22) The machine class (8088/86, v20/30, 80186, 80386/80486) is
- detected at startup. This may be used in future versions of the
- software to customize the time-critical software and available
- options to be run on the hardware.
-
-
- Version 2.07
-
- 23) Bug fixes in the BAUDOT/ASCII typeahead as well as changes to
- the operation of the typeahead buffer in AMTOR. Please note that
- all the keyboard data, the time key (ALT-T), and message buffers
- (ALT-1 thru 9) will now be collected in the typeahead buffer in
- the order that it was entered. This should work out better as you
- will be able to mix text for transmission either from buffers,
- and/or data from the keyboard without first waiting for the other
- to buffer to empty out.
-
- 24) Printer log feature toggled on/off using ALT-O.
-
- 25) All traffic sent using the "send files" (ALT-F) will now also
- be logged to disk.
-
-
- Version 2.08/9
-
- 26) Bug fixes associated with typeahead when ALT-B was used.
-
- 27) Bug fix in exception handler associated with printer OFFLINE.
-
- 28) F4, when used in ASCII/BAUDOT will terminate transmission
- only when the typeahead buffer is empty.
-
-
- Version 2.11
-
- 29) Does not require that DTR be connected any more. All data
- output is now routed through TD.
-
- 30) Special embedded control characters and controls the PTT.
- When using these, a submitted buffer will take control of the
- PTT. For an example, please see "test.tor".
-
-
- Version 2.12
-
- 31) When a user backspaced over more than one word in the
- typeahead buffer, "WORD MODE" got confused. This bug was fixed as
- well as cleaning up backspacing back to previous lines.
-
-
- Version 2.13
-
- 32) Fix "getting one behind" during buffer load. Don't backspace
- when buffer is empty.
-
-
- Version 3.00
-
- 33) Introduce color user-definable color scheme.
- 34) Scroll back receive data area via disk file
- 35) Output signal via BOTH TxD and DTR; DTR with usual
- OUTMASK option.
-
-
- Version 3.01/2
-
- 36) F8 should not use closeall, but close logfile only.
- 37) After ALT-P, restore operating mode
- 38) It appears that INMASK settings that inverts DTR also
- inhibits, BAUDOT/ASCII. Reset DTR setting for Baudot/ASCII
-
-
- Version 3.03
-
- 39) ALT_M to access DSP modem control
- 40) Sort *.tor buffers alphabetically
- 41) ALT_S sends a file continuously
- 42) ALT_Y shells out to Baycom
- 43) ALT_D to toggle RTTY diddle
- 44) Two-page help screen
- 45) Remove INMASK/OUTMASK options
-
- Version 3.03c
-
- 46) Restore the operating after returning from PC-PACTOR, i.e.
- after usage of ALT-P.
- 47) Message buffers now sorted alphabetically.
- 48) RTTY diddle control. Selectable in the configuration file,
- toggled using the ALT-D key.
- 49) ALT-P hot keys to PC-PACTOR.
- 50) ALT-Y hot keys to Baycom (note: Baycom is a copyrighted
- program by DL8MBT and DG3RBU - it is not supplied as part of
- the PCTOR package).
- 51) For users of the DSP modem, ALT-M brings up the DSP modem
- submenu. The user can select a modem of RTTY, AMTOR, PacTOR, or
- HF Packet.
- 52) ALT-S sends a file continuously.
- 53) Receive-only operation. This is selected from the command
- line by inluding /R.6.9 Newsletter December 1992
-
-
-
- With 1992 drawing to a conclusion, it may be worthwhile to
- reflect on some things accomplished with PCTOR and contemplate
- future milestones.
-
- This newsletter will concentrate on the origins of PCTOR its
- present status, and some thoughts on where things will be going
- in the near future.
-
- For those not too familiar with the software - PCTOR is a
- complete communications package for the PC or close compatibles.
- Its main purpose was to encode/decode AMTOR (SITOR) using the
- PC's on-board hardware in conjunction with a simple external HF
- modem, however rtty modes are now also supported. The interface
- with the HF modem is through a COM port. A hardware TNC is thus
- not required as all decoding is performed in software right on
- the PC. PCTOR is available from the library 6 area of the HamNet
- forum on CompuServe.
-
- PCTOR has grown and undergone several revisions over the past
- year. Presently version 2.03 is the latest. The user base has
- also grown over the past year and support has come from all over
- the world. I am extremely grateful for your interest and support.
- As to all those suggestions and bug reports from users - your
- contributions have been valuable. Some of your ideas have since
- been implemented, others are in the queue.
-
- By time that you receive this newsletter, a pre-release of my
- PACTOR program for the PC will be available. This version of
- PACTOR is for decoding and reading of PACTOR traffic and will
- automatically decode 100/200 baud ascii or Huffman text on-the-
- fly. This includes PACTOR "ARQ" and "UNPROTO" modes. Please check
- CompuServe HamNet library area 6 or send me a formatted disk and
- SASE mailer for a free Shareware copy.
-
- 6.8.1 PCTOR - some history.
-
-
-
- During 1978 I met Alan G3RSP/MM, who was maritime mobile on a
- tanker en route to the Persian gulf. I was then involved in
- operating an rtty SELCAL station at that time with the call
- ZS1HF. We had many interesting QSO's on every occasion that his
- ship sailed around the Cape of Good Hope. As a result of these
- contacts, I was introduced to Peter Martinez, G3PLX and his early
- AMTOR developments. At that time, there was only G3PLX and G3YYD
- on HF, with Alan using the ship's radio to communicate with Peter
- on AMTOR.
-
- Fortunately for me, I was using the same type of microprocessor
- chip that Peter was using - the Motorola M6800. Peter supplied
- the source code for AMTOR and with some further work, I was able
- to decode AMTOR on my homebrew 6800 computer. Everything needed
- to be made yourself - the modem, the decoder, and of course the
- modifications to the HF transceiver to improve changeover time.
- By the time that I had my first AMTOR QSO, I was ranked amateur
- number 15 or so on HF AMTOR - just an indication how fast things
- were happening.
-
- My own experimental efforts amounted to a single board system,
- complete with filter-type modem and tuning display. This system
- could handle baudot, ascii (at various rates), CW with automatic
- speed tracking, and AMTOR mode A, B and L. I called it a
- universal communications processor (UCP). Details were published
- for an amateur club project, however few systems were actually
- built. This system served my needs very well for several years
- and was a test bed for exploring many new ideas.
-
- During 1983 I came to Oregon as a visiting scientist, wrote the
- FCC examination, got my ticket and in due course as KC7WW, was
- listening for AMTOR. I subsequently met Bill, K4PA, who was
- experimenting with AMTOR as well, imagine - on a KIM
- microprocessor system! Bill supplied all the specifics on getting
- the necessary FCC permission to operate AMTOR in the USA. At that
- time this involved obtaining special temporary authority (STA).
-
- It was about 1984 that I learned of Paul, AD7I's Z-AMTOR, and
- shortly after that commercial developments from AEA and others.
- The publication of several technical articles followed. The
- introduction of the multi-mode TNC as a black box appliance
- introduced many new enthusiasts to the world of digital
- communications.
-
- During 1990 I started translating the M6800 code to 8088 Assembly
- language. The old hardware M6800 was just too cumbersome and
- inflexible to compete with the ubiquitous PC. Making AMTOR work
- on the PC's hardware was a challenge to say the least. With
- modern software tools, however, things became easier to debug
- than development work on the old embedded system.
-
- The first release of PCTOR was version 1.03, which was uploaded
- to CompuServe Hamnet library 6 during October 1991. It has been
- updated several times since then.
-
- It is with fond memories that I think of the early days. I am
- indebted to those that helped me along the way - in appreciation
- to the memory of Irv Hoff from whose work I learned about HF
- modems and much appreciation to Peter Martinez who shared the
- secrets of making AMTOR possible on a microprocessor.
-
- 6.8.2 The present status of PCTOR
-
-
-
- PCTOR consists of two major components: a low-level interface
- that handles critical timing at the hardware level, and a user
- interface. Previously the low-level interface and user interface
- was implemented as two separate modules, combining them made a
- lot of sense and simplified things for new users.
-
- The user interface follows the split screen format of operation
- that has become standard for this kind of communications
- operations. Data received through the software decoder is
- displayed in the upper window while the operator's keyboard
- entries are displayed in the lower window. In AMTOR mode, the
- display of characters on the upper display is actually an echo of
- what is being received at the remote station. This feedback helps
- an operator judge the state of a link - how well the flow is
- progressing, what has been sent already and what else is still
- waiting to be sent. This is one of the built-in characteristics
- of AMTOR.
-
- Two status lines keeps the user informed of real-time operational
- status of the digital translator. The main status line is on the
- very top of the display. It shows, besides the link status, other
- useful parameters such as path propagation delay, current
- callsign and selcal, and the current status of some
- user-controlled flags such as unshift-on-space (UOS),
- upper/lower case operation, and high reliability. The latest
- symbol that has been added is "δ", that is used to indicate
- whether "memory ARQ" is active or not. More about this feature
- later.
-
- The real-time clock on the upper status line may now be
- programmed in either local time or UTC.
-
- Part of the upper status line and a small portion of the upper
- split screen display is used for an on screen tuning indicator.
- This option is available only when a special modem is used with
- PCTOR. Details on this modem follow in the text below.
-
- The lower status line is located between the upper text display
- area and the lower text display area. It contains the name of the
- user's log file, logging program's name, and shows the current
- size of the user's keyboard buffer, i.e. the number of characters
- in the type-ahead buffer. This logging program is a new feature
- that was added to allow for the execution of a user-specified
- program when ALT-L is pressed. This allows ready access to a
- logging program via a hot key from PCTOR while the decoder
- remains running in the background. The user, however, has to
- supply his own logging program.
-
- A general "help" function is available through the ALT-H key
- where function key assignments, as well an explanation of the
- indicator symbols are given.
-
- In addition to AMTOR modes ARQ, FEQ, and "listen", ascii and
- baudot is now also supported at 45.45, 50, 75, and 110 baud.
- Please note that in order to use ascii and baudot, additional
- interface wiring is required.
-
- To further simplify operations, a pop-up menu system allows the
- user to change some functional parameters on-line. This pop-up
- menu system is complete with its own help function where all
- available features that may be accessed through the pop-up menu
- are listed. The latest additions to this menu are "O" and "P"
- options that allows the toggling between AMTOR, baudot, and ascii
- modes, and alters the baud rate for baudot or ascii modes of
- operation.
-
- In order to customize the state of options and other special
- items, a user-prepared configuration file is read when PCTOR
- starts up. The most recent keywords that have been added are
- LOGPROG, REFR, TUNING, WORD, and MARQ. LOGPROG allows the
- specification of the user's logging program. REFR sets the
- refresh rate of the status displays. TUNING activates the
- on-display bargraph tuning displays. WORD enables word-edit
- keyboard entry mode. MARQ activates the memory ARQ algorithm.
- Some of these features have been requested by users. Please note
- that TUNING and MARQ assumes that special hardware is present in
- the user's modem. More about this later in this newsletter.
-
- Further general features are available. Off-the-air received
- traffic may be captured in a text file. Automatic and manual
- identification and time-stamping facilities are provided. Sending
- of text files over the air is possible in all modes, recalling of
- canned buffers, i.e. CQ call, or brag tape, for transmission, at
- a keystroke.
-
- PCTOR supports the APlink protocol for full upper and lower case
- ascii. This is based on the "PLX"-method of upper/lower case with
- extensions as developed by Victor Poor (W5SMM).
-
- A "high" reliability option is included to improve received data
- integrity beyond the 3/4 (zeroes/ones) ratio test used in AMTOR.
-
- The Unshift-on-space (UOS) option have been available in earlier
- versions of PCTOR. It is particularly useful for baudot
- operation. This option switches the baudot case shift to upper
- case at the reception of a space character. Baudot is
- particularly prone to noise and often ends up in the wrong
- letter/figs case shift. UOS, resets the case to letter shift each
- time a space character is received. Based on the general
- assumption that a space character is mostly used to separate
- words, letter case is assumed. This method more often than not
- will allow better print under adverse conditions. Do not be
- concerned with all this case shifting if it does not make
- sense.It really comes from an earlier era of mechanical
- teleprinters. Most of these issues are now handled by the
- software anyhow.
-
- Baudot operators have all sorts of tricks to "help the print
- along", especially when conditions are marginal. The baudot
- "diddle" is one of them. This amounts to sending "idle"
- characters when the keyboard buffer is empty. These idle
- characters are carefully chosen to be either the ITA2 characters
- letter, figures, or in some cases "blank". PCTOR uses diddle in
- baudot mode.
-
- As mentioned above, a new modem with special features has been
- under development for usage with PCTOR. This development was
- essential to support new modes such as PACTOR. At the same time,
- however PCTOR's performance was enhanced through the use of
- sophisticated digital signal analysis. This modem is not a
- digital signal processing unit, however it is quite sophisticated
- and a good performer. The hardware lineup consists of a
- highpass/lowpass front end, bi-quad discriminator, active
- rectification, and low pass filter optimized for 200 Hz
- modulation rate. An 8-bit A/D convertor is included that is used
- by the software for analyzing recovered modulation signal in the
- memory ARQ algorithm. A ten element bargraph display is provided
- as a tuning indicator. Further details of the modem, and its
- availability in kit form, will be published shortly.
-
- Memory ARQ is an algorithm for intelligent error correction
- during ARQ (PCTOR has an option that allows AMTOR to make use of
- it as well). Briefly, during reception of AMTOR data blocks, the
- algorithm saves not only logical states of bits from the modem's
- slicer stage, but also saves the actual magnitude of the
- recovered modulation signal levels associated with each bit. This
- additional information thus indicates a confidence level
- associated with each logic level. When two or more blocks are in
- error, the algorithm proceeds to examine the confidence levels of
- individual bits for possible "reconstruction" of a good block
- from erroneous blocks. The actual details of the algorithm is
- somewhat more complex than this brief introduction.
-
- Besides the benefits gained by memory ARQ, useful time domain
- signal analysis is possible especially when coming across an
- unknown signal. Time and frequency domain analysis software are
- provided as an external executable program that is accessible via
- a hot key from PCTOR. Acquisition of signal data is then
- initiated and interfacing with the signal processing program is
- relatively smooth and unintrusive.
-
- Two graphical displays are shown. One panel shows the actual
- analog signal with its thresholded counterpart, the other panel
- shows the frequency domain (RMS power spectrum). A software
- controlled cursor (using the left/right arrow keys), allows
- inspection of power spectral peaks, while different levels of
- magnification of the analog signal is user selectable (using the
- up arrow key). Continuous conversions are performed while the ALT
- key is held down. When the ALT key is up, the present state of
- the graphs are frozen.
-
- Unfortunately this type of work is only feasible on faster class
- machines. A 386/25 with math co-processor or a 486 processor is a
- pleasure to use. The signal processing software, however, has
- been tested on a 8 Mhz XT without math co-processor where it took
- several minutes to run to completion. Presently only Hercules,
- EGA, and VGA display adapters are supported.
-
-
-
- 6.8.3 Future developments
-
-
-
- The modem development is in final stages of printed circuit
- layout. The details will be appearing shortly in one of the
- amateur or electronic hobbyist journals. A kit of parts will be
- also offered.
-
- There has been several requests for PACTOR capability. This will
- be the next major upgrade. Although I have been experimenting and
- testing PACTOR, the special modem was required to implement true
- memory ARQ. Without the A/D convertor addition, true memory ARQ
- is not possible, regardless of what you may have been told by
- others. If you have wondered of what PACTOR is like - my
- experience has been that it is really fun to operate when
- conditions are good. If you have ever tried HF packet, PACTOR is
- a great improvement. However, when conditions are marginal,
- performance degrades rapidly, delays become uncomfortably long,
- and not even memory ARQ seem to be of much use. This is where you
- wish that it could have reverted to AMTOR. I am of the opinion
- that it may become popular with some higher powered
- traffic-handling stations. This is, however, my own opinion.
-
- Several requests were for the inclusion of embedded control
- functions in text files. For example: a user wants to send an
- automatic CQ while contesting: A text file is prepared that
- contains the body of the CQ message including some special
- control functions. The text file is submitted for transmission in
- a similar same way than a buffer message is sent. The following
- pseudocode shows the procedure.
-
-
-
- Script submission for automatic transmission
-
- 1) START:
- 2) <initiate FEC transmission>
- 3) CQ CONTEST DE KC7WW KC7WW (KCWW)
- 4) CQ CONTEST DE KC7WW KC7WW (KCWW)
- 5) AR PSE ARQ KN
- 6) <terminate FEC transmission>
- 7) <wait for an ARQ link (timeout=30 seconds)>
- 8) <if it timed out> go back to START
- 9) <cancel automatic mode and enter normal keyboard mode>
-
- Note: F7 flushes the text buffer, F10 forces standby mode.
-
- This simple example shows several kinds of control symbols, i.e.
- LABELS, start/stop FEC transmission, and wait with timeout - a
- branch address for timeout is supplied. A small language set to
- support some of PCTOR's built-in features will be developed. The
- script will be parsed for syntax and semantics before actual
- submission occurs.
-
-
- There have been several requests for running PCTOR in a
- multitasking environment. This is of course possible, given that
- PCTOR has guaranteed one millisecond interrupt rate for low level
- services. Although this timing requirement hardly impacts
- performance on a 386 or 486 type machine, it is unfortunate that
- some of the popular multitaskers require the same hardware that
- PCTOR uses for their pre-emptive scheduling. In the end someone
- usually looses out. Windows 3.1 on the other hand, being a
- co-operative multitasker, does tolerate this kind of intervention
- but is not considered "well behaved". It is uncertain what future
- versions of Windows will allow. It will be logical to develop a
- DLL that contains the low level services as an embedded device
- driver that will guarantee such high priority interrupts. The
- PCTOR user interface will then be using the familiar Windows CUA
- format.
-
- I apologize for the inadequacies of the documentation, especially
- for newcomers to the digital modes. It is my impression that most
- new users either had some earlier experience with AMTOR, or was
- very knowledgeable and capable of putting together all the
- required bits and pieces. There appears to be a lack of the
- basics for AMTOR, but also what these signals sound like. So,
- this is perhaps one area that hopefully could be improved. It
- also appears that a complete bibliography for reference purposes
- would be helpful.
-
- The inclusion of more digital signal processing is a possibility.
- Not only could we benefit from noise reduction algorithms but
- also from DSP modems that has been tailored for optimum
- performance. This approach uses software to adapt filter
- parameters and usually results in really sharp filters. An
- external dedicated DSP approach, or perhaps a low-cost sound
- board could be used. This kind of development is very
- challenging, yet holds promise for the future.
-
- The baudot and ascii mode presently lacks "autostart" and "anti-
- space" facilities. If anyone is interested in these features,
- digital equivalents are possible that works quite well.
-
- Work on PCTOR has always been a challenge and very rewarding. The
- order that features are implemented is dictated mostly by what
- available time I have at hand, the hardware requirements, and
- often doing the fun things first. A lot of time is also spent on
- improving things, often fine tuning the time-critical parts, or
- fixing irritating bugs.
-
- Should there perhaps be something that you consider needing
- attention, please let me know and we can see what could be done
- about it.
-
- To contact me, you may leave an e-mail message for me on
- CompuServe (70730,3472), or leave a message at WA8DRZ via packet
- or Aplink.
-
- KC7WW @ WA8DRZ.#NOCAL.CA.USA
-
- If all else fails - write to me at the address below.
-
- 6.10 1993 Newsletter
-
-
- This newsletter is to update registered users and those
- interested in PCTOR and PC-PACTOR on developments during 1993.
- Some background will be discussed and future trends also
- presented.
-
- I thank those from whom I have heard over the past year. Your
- contributions and support are always greatly appreciated.
-
-
-
- ┼ This issue of the newsletter is dedicated in memory
- of Pim Woest, PA3AGG. Pim was one of the first to
- experiment with PCTOR - he became a silent key on
- January 31st, 1993. We will miss him.
-
-
-
- Newsletter Summary:
-
- 1. PCTOR
- 2. PC-PACTOR
- 3. HF Modem Developments
- 4. Future Enhancements
-
-
-
- 1. PCTOR
-
- What is it? For those not too familiar with the software: PCTOR
- is a complete amateur radio communications package for the PC or
- close compa-tibles for operating AMTOR (SITOR), RTTY, and ASCII.
- An external HF modem is required to convert received audio to COM
- port signals (RS232 levels). As decoding is performed in software
- right on the PC, there is no need for a hardware TNC.
-
- The 1992 newsletter covered software up to version 2.03 (included
- in PCTOR documentation). PCTOR has grown and undergone several
- revisions over the past year. Versions 2.04 - 2.08 included
- several bug fixes and improvements for a cleaner interface with
- DOS.
-
- When the HF analog modem, AN-93, became available, memory ARQ for
- AMTOR and an on-screen tuning display, was added (please see
- section 3 on: HF modems).
-
- Version 3.0 introduced a scrollable receive display and user-
- definable screen colors.
-
- Version 3.03 is currently under development. It includes support
- for a new DSP modem and allows "hot keys" to operate PC-PACTOR or
- HF packet from PCTOR. Additional features for customization of
- the startup file includes selection of the operating mode and
- baud rate. For SWL listeners, transmit features may now be
- disabled and the receive screen extended to fully use the
- additional display lines.
-
- There has been considerable confusion over which RS232 signals
- are used to transmit data. This came about in an effort to
- simplify the hardware interface: It was found that AMTOR could
- use the "break" mechanism to send data through the "Td" line.
- This simplified the interface to four lines, i.e. Rd/DCD - for
- input signals, and Td/RTS for output signals. Unfortunately, this
- did not work with some older serial ports. For compatibility
- sake, both Td and DTR was then made available for data output.
- When the DSP project came along, DTR was needed for DSP control.
- That is why version 3.03 now only supports serial ports that can
- switch data fast enough through Td.
-
-
- 2. PC-PACTOR
-
-
- What is it? PC-PACTOR is a program for the PC to decode, read and
- transmit PACTOR traffic. It will automatically decode 100/200
- baud ASCII or Huffman-compressed text.
-
- Version 0.03 was released in December 1992 for monitoring PacTOR
- traffic only. I have since had a lot of requests for a full
- transmit version of the program. The current version of PC-PACTOR
- is 0.16 and includes the ASCII FEC transmit capability, traffic
- logging and file transmission. Version 0.20 is presently under
- development for full ARQ capability.
-
- I do ask your patience as there are some major implementation
- issues to be solved. First is to achieve the 15ppm timing
- requirement. The PC clock was never designed for this kind of
- accuracy.
-
- PacTOR is based on a proprietary standard developed by SCS,
- Germany. In order to receive support from SCS, a license fee has
- to be paid. Presently, this is why all other amateur radio
- implementations of PacTOR are licensed. SCS, however, gave
- permission to develop a Shareware version but indicated that no
- support would be available.
-
- Things went fairly smooth during development until it became
- clear that there are a number of undocumented exceptions that
- needed clarification. To date I have not been able to obtain all
- the necessary details from SCS to resolve these outstanding
- issues. I will persist, however, in pursuing these on my own,
- though it may take a little longer.
-
- Please note that version numbers below 1.00 indicates
- "experimental" status and should be considered that.
-
- 3. HF Modem Developments
-
-
- Due to numerous requests for a simple yet good performing HF
- modem for use with PCTOR and PC-PACTOR, the AN-93 was developed.
- The design is a conservative active filter approach using 170 Hz
- shift with 2125/2295 Hz tones for data rates to 200 baud. The
- unit is intended for direct FSK operation. The computer interface
- is through a serial port that is compatible with PCTOR.
-
- A 10-segment bargraph display is provided for tuning purposes. In
- addition, an A/D convertor is provided that samples recovered
- modulation for implementation of soft memory ARQ by the PC. In
- addition, the A/D signal is used for an on-screen tuning display.
- The A/D convertor interfaces to the PC through a parallel port
- interface.
-
- To those interested, there still remains a few AN-93 kits still
- at $135 plus postage.
-
- A considerable amount of effort was spent on studying DSP math,
- algorithms, and hardware. This led to the development of a
- prototype DSP unit for HF digital. A small production of these
- units followed. This was known as the DSP-100 project. Although
- an excellent performer, the unit proved to be overly complex and
- expensive. After all, it appears that the software TNC approach
- is attractive because of its low cost.
-
- Further DSP developments using a $99 evaluation module from Texas
- Instruments, called the "DSK" (DSP Starter's Kit) proved very
- promising. The DSK is based on a 40 MHz 320C26 DSP chip and
- includes a 44kHz, 14 bit A/D convertor.
-
- DSP applications developed for PCTOR now includes high
- performance HF modems for RTTY, AMTOR, PacTOR, and HF packet. The
- DSK shares the serial port with PCTOR. User-selected modems are
- downloaded from the PC to the DSK's on-chip memory at a 115200
- baud.
-
- Some valid concern has been expressed about the "delay"
- introduced by such a DSP and subsequent timing issues. This delay
- time is known as "group delay" and is the due to the time taken
- for digital data to ripple through the DSP's shift registers. I
- have measured this delay to be approximately 7mS longer than the
- AN-93. This has not yet proved to be a problem for me, but if it
- does, there are ways to reduce the group delay.
-
- Which is better - the AN-93 analog or the DSP unit? A unit such
- as the AN-93 is very good at what it is designed for, however,
- when attempting to make it work at too wide a range of baud
- rates, some compromise is necessary. In such a case, versatility
- is often traded for ultimate performance. The DSP algorithms on
- the other hand, are customized for the application at hand and is
- expected to deliver uncompromized performance.
-
- The implementation of very efficient filters is a further
- advantage of the DSP approach. The modems used in this
- application uses 80th order FIR filters, has outstanding
- selectivity, and good dynamic range.
-
- It is expected that in time, further digital modem code will
- become available in conjunction with yet newer modes. All that
- would be required is new DSP code and decoding software on the
- PC.
-
-
-
- 4. Future enhancements
-
-
- The most-requested enhancement appears to be for a full PacTOR
- implementation. This will receive very high priority.
-
- The script processor for PCTOR remains to be further developed.
- This feature will allow the user to embed control characters in
- submitted text. These control characters will allow execution of
- "test and branch" dependant on internal status variables and
- allow "looping" constructs. This would allow special operations,
- such as needed for contest mode.
-
- Both hardware and software developments using DSP will continue.
- The DSK code may eventually be ported to a PC Soundcard as DSP-
- based Soundcard technology reaches maturity. There already are
- innovative applications for CW, SSTV, and WEFAX for Soundcards.
- The prohibitive cost of development software remains a problem.
- The DSK will be used in the meantime.
-
- There are plans for development of a new mode based on ideas from
- MIL-STD-188-110. The new mode is expected to fill the need for
- more robustness than PacTOR with data between 75 and 300 bps
- suitable for HF networking. DSP modems will be used to implement
- m-ary modulation at low baud rate, higher bit rates are achieved
- by transmission of multiple bits per baud. This new mode will
- rely on error-correction techniques to achieve coding gain and
- robustness.
-
- A draft of specifications will be available in the near future
- and will be submitted to various peer forums for input. Those
- interested in participating on this project, please contact me.
-
- 7.0 Disclaimer
-
-
-
- The author, Johan Forrer KC7WW is not responsible for any damage,
- injury, loss of profit or gain associated with the use,
- installation, or application of this software.
-
-
-
- November 1993
- J.B.Forrer KC7WW
- 26553 Priceview Drive
- Monroe, OR 97456
- United States of America
-
-
-
- e-mail: forrerj@FRL.orst.edu
- CompuServe: 70730,3472